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FINAL OFFICE ACTION 

0. This office action is in response to Applicants' Amendment of 29 September 2004 , 

0,1 Claims 1-9, 11-28 and 30-31 are amended; Claims 34-37 are added. Claims 1-37 remain 

pending. 

0.2 The rejections under 35 U.S.C. 101 and 112 and objections of record are withdrawn in 
response to Applicants' amendment 

0,3 The indicated allowability of Claim 29 of record is maintained. 

0. 4 The prior art rejections of record are maintained in response to Applicants' Amendments. 

Response to Arguments 

1. Applicants' arguments have been fully considered: they are partly persuasive. As a 
result, Claims 28, 30-31 are allowed along with previously allowed Claims 29, 33-34. The 
newly amended context-relevant Umitation is disclosed in US Pat. # 5,067,104 to 
Krishnakumar et al. 

REMARKS 

2. In response to Claims 1-26, 34-37, AppHcants argue, on page 16 et seq., that the prior art 
of record does not teach the claimed invention, i.e., unidirectional protocol, context-relevant 
information. 

Examiner notes that the prior art of record does not restrict the disclosed protocol 
exclusively to bi-directional protocol or to context-irrelevant information as alleged by 
Applicants. 

Therefore, said claims are not distinguished over the prior art of record. 
2.1 In response to Claims 1-26, 34-37, Applicants also allege, on page 18 last para., that 
there is no motivation to combine references as per formulation of record. 
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Examiner disagrees and notes that: To establish a prima facie case of obviousness, there 
must be some suggestion or motivation, either in the references themselves or in the knowledge 
generallv available to one of ordinary skill in the art , to modify the reference or to combine 
reference teachings. In re VaecK 947 F.2d 488, 20 USPQ2d 1438 (Fed. Cir. 1991). Therefore, 
such suggestion or motivation may be found not only in the references but also in the knowledge 
generallv available to one of ordinary skill in the art . 

Hence, "In determining the propriety of the Patent Office case for obviousness in the first 
instance, it is necessary to ascertain whether or not the reference teachings would appear to be 
sufficient for one of ordinary skill in the relevant art having the reference before him to make the 
proposed substitution combination, or other modification." In re Linter, 458 F.2d 1013, 173 
USPQ 560, 562 (CCPA 1972). 

Obviousness can only be established by combining or modifying the teachings of the 
prior art to produce the claimed invention where there is some teaching, suggestion, or 
motivation to do so found either in the references themselves or in the knowledge generally 
available to one of ordinary skill in the art. In re Fine, 837 F.2d 1071, 5 USPQ2d 1596 (Fed. Cir. 
1988); In re Jones, 958 F.2d347, 21 USPQ2d 1941 (Fed. Cir. 11192). 

The rationale to modify or combine the prior art does not have to be expressly stated in 
the prior art; the rationale may be expressly or impliedly contained in the prior art or it may be 
reasoned from knowledge generally available to one of ordinary skill in the art, established 
scientific principles, or legal precedent established by prior case law. In re Fine, 837 F. 2d 1071, 
5 USPQ2d 1596 (Fed. Cir. 1988); In re Jones, 958 F.2d 347, 21 USPQ2d 1941 (Fed. Cir. 1992). 
See also In re Eli Lilly & Co., 902 F.2d 943. 14 USPQ2d 1741 (Fed Cir. 1990) (discussion of 
reliance on legal precedent); In re Nilssen, 851 F.2d 1401, 7 USPQ2d 1500, 1502. (Fed Cir. 
1988) (references do not have to expUcitly suggest combining teachings); Ex parte Clanp. 227 
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USPQ 972 (Bd Pat. App. & Inter. 1985); and Ex parte Levengood, 28 USPQ2d 1300 (Bd. Pat. 
App. & Inter. 1993) (reliance on logic and sound scientific reasoning). 

Also in reference to Ex parte Levengood, 28USPQ2d, 1301, the Court stated, 
"Obviousness is a legal conclusion, the determination of which is a question of patent law. 
Motivation for combining the teachings of the various references need not be explicitly found in 
the references themselves, In re Keller, 642 F.2d 413, 208 USPQ 871 (CCPA 1981). Indeed, the 
examiner may provide an explanation based on logic and sound scientific reasoning that will 
support a holding of obviousness. In re Soli, 317 F.2d 941, 137 USPQ 797 (CCPA 1963)." 

Claim Objections 

3. The claims in passim, e.g., Claims 1, 28, are objected to for including "capable of:' It 
has been held that the recitation that an element is "capable of " performing a function is not a 
positive limitation but only requires the ability to so perform. It does not constitute a limitation in 
any patentable sense. In re Hutchison, 69 USPQ 138. 

Claim 37 is objected to for not further limiting Claim 35. 
Appropriate correction is required. 

Claim Rejections - 35 USC § 103 

4. Claimfs) 1-3. 35-37 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters 
(US Patent No. 6,684,399) in further view of Krishnakumar et al. 

As per claims 1, 35-37, 

TCP substantially teaches of creating and transmitting data signals (i.e. 
segments/packets/frames) through a communication medium to receivers, see paragraph 1 of 
page 4. TCP further teaches of computing a checksum over the data, see Checksum paragraph 
on page 16. TCP fixrther teaches of providing an integrity element, see pages 15-17, which the 
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Examiner is interpreting as a header since it is essentially made of data (i.e. checksum, size, 
etc. . .) that will help determine the validity of the data frame. On pages 15-17, TCP teaches of an 
integrity element (header) that contains the checksum and how the integrity element (header) 
encapsulates (or associated with) one frame (or packet). On page 4, paragraph 3 teaches how the 
integrity element (header), specifically the checksum, can be used to determine if the received 
frame/data subset (or packet) is intact/valid or damaged. Further, in paragraph 1 of page 15, 
TCP teaches how the header and data are sent together as segments (i.e. broadcast signals). In 
paragraph 1 of page 4, TCP fiirther teaches that the broadcast signals (i.e. segments) are 
transferred in both directions, hence TCP teaches the limitation of transmitting signals to 
receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals over an 
established connection, hence TCP teaches the limitation of transmitting through communication 
medium to the device. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents.} Therefore, it would 
have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby ''content information is broken down and analyzed'' {See Grooters, Fig. 3 at step 
326.} 
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While TCP/Grooters substantially the claimed data signal generation, TCF/Grooters 
fails to disclose in detail that data signal comprises context-relevant information. 

However Krishnakumar et aL, in an analogous art, discloses, in ''Programmable 
protocol engine having context free and context dependent processes'' a network 
communications wherein such techniques are described. {See Krishnakumar, Id., Fig. 5:Block 
142. 




Therefore, it would have been obvious to a person having ordinary skill in the art at the 
time the invention was made to modify the procedure in TCP/Grooters by including therein a 
context dependent techniques as taught by Krishnakumar, because such modification would 
provide the procedure disclosed in TCP/Grooters with a technique whereby "Connection context 
data base process 14 also receives information from the parser and it comprises a sequence 
number and state variable generator process 141 which supplies information to a receiver link 
context database 142. Database 142 also receives infofmation from the parser, and it delivers 
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infonnation to acknowledge generator process 143. Process 143 supplies information to 
transmitter link context database 144.. " {See Krishnakumar, Fig. 3 at Block 142.} 

As per claim 2, 

TCP/Grooters further teaches of an integrity element (header) that comprises a size 
value, see page 17, paragraph 2 where the TCP length is described. Further, it would have been 
obvious to one of ordinary skill in the art to include both, the checksum operation and seed value. 
If these values were not previously agreed upon by the communication devices, then one of 
ordinary skill in the art would obviously want to transmit these values so as to allow the 
receiving device to be able to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
disclosing known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

As per claim 3, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222, Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
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time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Intemet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). Also see Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup- language/XML documents. 

4.1 Claim(s) 4 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 - 
Transmission Control Protocol Specification (hereinafter TCP), Krishnakumar and Grooters 
(US Patent No. 6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 4, 

TCP/Grooters as noted above in claim 1 and later in claim 3 substantially teaches of the 
limitations of claim 4. TCP/Grooters does not teach of transmitting the signal as a difftise 
infrared signal. Nonetheless, TCP/Grooters does teach of establishing communication 
connections. 

Specs, in an analogous art, teaches of difftise optical communication as a common optical 
communication protocol, see paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 
communication protocol. This modification would have been obvious because one of ordinary 
skill in the art would have been motivated by the suggestion provided by Specs that difftise 
optical communication protocol is a commonly used protocol and hence communication method. 

4.2 Claimfs) 5-9 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 
- Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters (US Patent 
No. 6,684,399) and Krishnakumar et al. 

As per claim 5. 
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TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
transmit data, see paragraph 1 on page 4 and pages 15-17, and of using the checksum to ensure 
reliabiUty , see paragraph 3 , page 4 . By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data. When read in this hght, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets/frames as well. Further, with TCP teaching of 
headers and what they are comprised of on pages 15-17, it is clear that TCP teaches of 
determining the contents of the integrity element (header). Further, TCP exphcitly teaches of 
using the checksum (which is one of the contents of the header/integrity element) to disregard 
damaged segments/packets, see paragraph 3 on page 4. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} Therefore, it would have been obvious to a person having ordinary skill in the art 
at the time the invention was made to modify the procedure in TCP by including therein a 
parsing technique as taught by Grooters, because such modification would provide the 
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procedure disclosed in TCP with a technique whereby ''content information is broken down and 
analyzed'' {See Grooters, Fig. 3 at step 326.} 

While TCP/Grooters substantially the claimed data signal generation, TCF/Grooters 
fails to disclose in detail that data signal conprises context-relevant information. 

However Krishnakumar et aL, in an analogous art, discloses, in ''Programmable 
protocol engine having context free and context dependent processes" a network 
communications wherein such techniques are described. {See Krishnakumar, Id., Fig. 5:Block 
142. 

Therefore, it would have been obvious to a person having ordinary skill in the art at the 
time the invention was made to modify the procedure in TCP/Grooters by including therein a 
context dependent techniques as taught by Krishnakumar, because such modification would 
provide the procedure disclosed in TCP/Grooters with a technique whereby "Connection context 
data base process 14 also receives information from the parser and it comprises a sequence 
number and state variable generator process 141 which supplies information to a receiver link 
context database 142. Database 142 also receives information from the parser, and it delivers 
information to acknowledge generator process 143, Process 143 supplies information to 
transmitter link context database 144.. " {See Krishnakumar, Fig. 3 at Block 142.} 

As per claim 6, 

TCP/Grooters substantially teaches, as noted above in claim 5, the limitations of claim 6. 

With respect to the hmitations of claim 6, TCP further teaches of a checksum that is 
calculated over its associated frame/packet, see pages 15-17 and specifically the Checksum 
paragraph of page 16. 

As per claims 7 and 8, 

TCP/Grooters substantially teaches, as noted above in claim 5, the hmitations of claim 7. 
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With respect to the limitations of claim 7, TCP further teaches of checking a checksum at 
the receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. Clearly, if the 
checksum is calculated upon receipt and matches the transmitted checksum, then the 
segment/frame/packet will be validated, otherwise, when the two checksums don't match, the 
"damaged" one will be discarded or invalidated. 

As per claim 9, 

TCP/Grooters substantially teaches, as noted above in claim 5, the limitations of claim 9. 

With respect to the limitations of claim 9, TCP further teaches of an integrity element 
(header) that comprises a size value, see page 17, paragraph 2 where the TCP length is described. 
Further, it would have been obvious to one of ordinary skill in the art to include both the 
checksum operation and seed value. If these values were not previously agreed upon by the 
communication devices, then one of ordinary skill in the art would obviously want to transmit 
these values so as to allow the receiving device to be able to calculate the checksum and 
validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
disclosing known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
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calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

4.3 Claimfs) 10 and 11 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US 
Patent No. 6,684399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 10 

TCP/Grooters, as noted above in claim 5, substantially teaches of the limitations of 
claim 10. TCP/Grooters does not teach of transmitting the signal as a diffuse infrared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffuse optical communication as a common optical 
communication protocol, see lines 3-6 of paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 
communication protocol. This modification would have been obvious because one of ordinary 
skill in the art would have been motivated by the suggestion provided by Specs that diffuse 
optical communication protocol is a commonly used protocol and hence communication method. 

As per claim 1 1 , 

TCP/Grooters, as noted above in claim 5 and later in claim 10, substantially teaches of 
the limitations of claim 11. TCP/Grooters does not teach of data signal being created by 
modulating an electric light. 

Specs, in an analogous art, teaches of modulating an electric light to generate optical 
signals as being known in the art, see lines 1-5 of paragraph 161 of page 55. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to create frames/packets/broadcast signal of TCP/Grooters by modulating an electric 
light. This modification would have been obvious to one of ordinary skill in the art would 
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because one skilled in the art would have known of the techniques as mentioned by Specs. 
Further, since Specs discloses that the techniques are known in the art, one skilled in the art 
would readily be able to modulate Ught so as to generate the optical signals with which the data 
signals are transferred over. 

4.4 Claim(s) 12,13 and 15 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) in view of Grooters 
(US Patent No. 6,684,399) and Krishnakumar. 

As per claim 12, 

TCP substantially teaches of creating and transmitting data signals (i.e. packets/frames) 
through a communication medium to receivers see paragraph 1 of page 4. TCP further teaches 
of computing a checksum over the data, see Checksum paragraph on page 16. TCP further 
teaches of providing an integrity element, see pages 15-17, which the Examiner is interpreting as 
a header since it is essentially made of data (i.e. checksum, size, etc..) that will help determine 
the validity of the data frame. On pages 15-17, TCP teaches of an integrity element (header) that 
contains the checksum and how the integrity element (header) encapsulates (or associated with) 
one frame (or packet). On page 4, paragraph 3 teaches how the integrity element (header), 
specifically the checksum, can be used to determine if the received frame/data subset (or packet) 
is intact/valid or damaged. Further, in paragraph 1 of page 15, TCP teaches how the header and 
data are sent together as segments (i.e. broadcast signals). In paragraph 1 of page 4, TCP further 
teaches that the broadcast signals (i.e. segments) are transferred in both directions, hence TCP 
teaches the limitation of transmitting signals to receivers. In paragraph 6 of page 40, TCP further 
teaches of transmitting the signals over an established connection, hence TCP teaches the 
limitation of transmitting through communication medium to the device. 
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While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents.} Therefore, it would 
have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby ''content information is broken down and analyzed'' {See Grooters, Fig. 3 at step 
326.} 

While TCP/Grooters does not explicitly teach of making the transmission available for 
handheld devices, it would have been obvious to one of ordinary skill in the art at the time the 
invention was made to make the broadcast signal available for a handheld device. Handheld 
devices (i.e. PDAs) are essentially handheld computers that can process information whether 
received via their infrared port or through their physical port. One skilled in the art would 
obviously want a handheld device to be able to receive information so as to be able to 
communicate with it. 

Further, while TCP does not expHcitly teach of apparatuses, devices, or computer 
readable executable code embedded to carry out the methods taught, Grooters does in Fig. 3 
server 212. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to implement the teachings in some type of hardware or computer 
executable code once the method is known/determined. 
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While TCP/Grooters substantially the claimed data signal generation, TCP/Grooters 
fails to disclose in detail that data signal comprises context-relevant information. 

However Krishnakumar et aL, in an analogous art, discloses, in ''Programmable 
protocol engine having context free and context dependent processes'' a network 
communications wherein such techniques are described. {See Krishnakumar, Id., Fig. 5: Block 
142. 

Therefore, it would have been obvious to a person having ordinary skill in the art at the 
time the invention was made to modify the procedure in TCP/Grooters by including therein a 
context dependent techniques as taught by Krishnakumar, because such modification would 
provide the procedure disclosed in TCP/Grooters with a technique whereby "Connection context 
data base process 14 also receives information from the parser and it comprises a sequence 
number and state variable generator process 141 which supplies information to a receiver link 
context database 142. Database 142 also receives information from the parser, and it delivers 
information to acknowledge generator process 143. Process 143 supplies information to 
transmitter link context database 144.. " {See Krishnakumar, Fig. 3 at Block 142.} 

As per claim 13, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of ahnost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). 
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As per claim 15, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 

i 

of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the recei^ang device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

4.5 Claimfs) 14 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 793 - 
Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent No. 
6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 14. 

TCP/Grooters as noted above in claim 12 substantially teaches of the limitations of 
claim 14. TCP/Grooters does not teach of transmitting the signal as a difftise infrared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of difftise optical communication as a common optical 
communication protocol, see paragraph 88 on page 28. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP using the optical 
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communication protocol. This modification would have been obvious because one of ordinary 

skill in the art would have been motivated by the suggestion provided by Specs that diffuse 

optical communication protocol is a commonly used protocol and hence communication method. 

4.6 Claimfs) 16-19 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 

No. 6,684,399). 

As per claim 16, 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
transmit data, see paragraph 1 on page 4 and pages 15-17 and of using the checksum to ensure 
rehabiUty, see paragraph 3, page 4. By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data When read in this Ught, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets as well. Further, with TCP teaching of headers and 
what they are comprised of on pages 15-17, it is clear that TCP teaches of determining the 
contents of the integrity element (header). Further, TCP exphcitly teaches of using the checksum 
(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. TCP further teaches of a checksum that is 
calculated over its associated frame/packet, see pages 15-17 and specifically the Checksum 
paragraph of page 16. TCP fiirther teaches of checking a checksum at the receiver to ensure that 
the segment is not damaged, see paragraph 3 of page 4. Clearly, if the checksum is calculated 
upon receipt and matches the transmitted checksum, then the segment/frame/packet will be 
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validated, otherwise, when the two checksums don't match, the "damaged" one will be discarded 
or invalidated. Further, TCP teaches of passing the frames/segments/packets on if the 
checksums match, see paragraph 3 of page 4, specifically where TCP mentions discarding 
damaged segments (i.e. segments in which the checksums do not match) and keeping/passing on 
those that do match. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} 

While TCP does not explicitly teach of apparatuses, devices, or computer readable 
executable code embedded to carry out the methods taught, it would have been obvious to one of 
ordinary skill in the art at the time the invention was made to implement the teachings in some 
type of hardware or computer executable code once the method is known/determined. 

As per claim 17, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222, Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
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comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). Also see Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents. 
As per claim 18. 

TCP fiirther teaches of discarding the frames/segments/packets on if the checksums 
match, see paragraph 3 of page 4, specifically where TCP mentions discarding damaged 
segments (i.e. segments in which the checksums do not match). 

As per claim 19, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 
of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the receiving device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
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calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

4.7 Claimfs) 20-22 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 
No. 6,684,399) and Krishnakumar. 

As per claim 20, 

TCP substantially teaches of creating and transmitting data signals (i.e. packets/frames) 
through a communication medium to receivers see paragraph 1 of page 4. TCP further teaches 
of parsing (or packeting or packaging) bytes into frames (or packets) containing a subset of the 
bytes, see paragraph 1 of page 4. TCP further teaches of computing a checksum over the data, 
see Checksum paragraph on page 16. TCP further teaches of providing an integrity element, see 
pages 15-17, which the Examiner is interpreting as a header since it is essentially made of data 
(i.e. checksum, size, etc. . .) that will help determine the validity of the data frame. On pages 15- 
17, TCP teaches of an integrity element (header) that contains the checksum and how the 
integrity element (header) encapsulates (or associated with) one frame (or packet). On page 4, 
paragraph 3 teaches how the integrity element (header), specifically the checksum, can be used 
to determine if the received frame/data subset (or packet) is intact/valid or damaged. Further, in 
paragraph 1 of page 15, TCP teaches how the header and data are sent together as segments (i.e. 
broadcast signals). In paragraph 1 of page 4, TCP further teaches that the broadcast signals (i.e. 
segments) are transferred in both directions, hence TCP teaches the limitation of transmitting 
signals to receivers. In paragraph 6 of page 40, TCP further teaches of transmitting the signals 
over an established connection, hence TCP teaches the limitation of transmitting through 
communication medium to the device. 
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While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4, TCP fails to particularly mention the 
term: "parsing." 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id., Fig. 3 at step 326 wherein parsing routine is 
executed for broadcasting data/HTML/markup-language/XML documents.} Therefore, it would 
have been obvious to a person having ordinary skill in the art at the time the invention was made 
to modify the procedure in TCP by including therein a parsing technique as taught by Grooters, 
because such modification would provide the procedure disclosed in TCP with a technique 
whereby content information is broken down and analyzed" {See Grooters, Fig. 3 at step 
326.} 

While TCP does not explicitly teach of making the broadcast signal available for 
transmission to a receiving device, Grooters does disclose such data transfer in Fig. 3 server 212 
or network 222. Or equivalently, it would have been obvious to one of ordinary skill in the art at 
the time the invention was made to make the broadcast signal available for the transmission. 
TCP, in paragraph 6 of page 40, does teach of a connection that is established and data is 
communicated between senders and receivers. Therefore making the signal available for 
transmission to a receiving device must occur since TCP teaches that a connection is estabhshed 
and data/segments are communicated/exchanged. 

While TCP/Grooters substantially the claimed data signal generation, TCP/Grooters 
fails to disclose in detail that data signal comprises context-relevant information. 

However Krishnakumar et al., in an analogous art, discloses, in ''Programmable 
protocol engine having context free and context dependent processes'' a network 
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communications wherein such techniques are described. {See Krishnakumar, Id., Fig. 5: Block 
142. 

Therefore, it would have been obvious to a person having ordinary skill in the art at the 
time the invention was made to modify the procedure in TCP/Grooters by including therein a 
context dependent techniques as taught by Krishnakumar, because such modification would 
provide the procedure disclosed in TCP/Grooters with a technique whereby ''Connection context 
data base process 14 also receives information from the parser and it comprises a sequence 
number and state variable generator process 141 which supplies information to a receiver link 
context database 142. Database 142 also receives information from the parser, and it delivers 
information to acknowledge generator process 143, Process 143 supplies information to 
transmitter link context database 144.. " {See Krishnakumar, Fig. 3 at Block 142.} 

As per claim 21, 

TCP further teaches of an integrity element (header) that comprises a size value, see page 
17, paragraph 2 where the TCP length is described. Further, it would have been obvious to one 
of ordinary skill in the art to include both the checksum operation and seed value. If these values 
were not previously agreed upon by the communication devices, then one of ordinary skill in the 
art would obviously want to transmit these values so as to allow the receiving device to be able 
to calculate the checksum and validate/invalidate successfully. 

Further, with respect to the operator to compute the checksum, as is common in the art, 
checksums are typically calculated with XORs or summing in mod 2 arithmetic. Further, the 
specifications do not teach of any checksum calculation techniques other than XOR when 
speaking known techniques to calculate the checksum. Therefore the need to transmit the 
operator along with the integrity element is not clear (especially if the only admitted operation is 
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XOR). While it is understood that checksum can be calculated various specific ways (i.e. CRC), 
the operator used is typically the XOR. 

It is further unclear why the checksum operation and seed values are not uniformly 
agreed upon beforehand so as to save bandwidth (i.e. have to transmit less bits) and save 
calculation time (i.e. immediately calculate checksum upon receiving as opposed to receiving the 
packet and read out the operation and then calculate the checksum). 

As per claim 22, 

Grooters does disclose marked-up-language/XML documents in Fig. 3 server 212 or 
network 222, Or equivalently, it would have been obvious to one of ordinary skill in the art at the 
time the invention was made to have the data signal contain an XML element. Essentially, this is 
akin to a user on a network, possibly the Internet, requesting an XML document (which 
obviously contains XML elements), having the document framed (or packeted up) and 
transmitted off to the receiver. Simply put, the data that the frame/packet contains can be 
comprised of almost any type of transferable data, (i.e. XML document with XML elements, 
HTML document etc). 

4.8 Claimfs) 23 and 24 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over 
RFC 793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US 
Patent No. 6,684,399) in view of admitted prior art "Specifications" (hereinafter Specs). 

As per claim 23 

TCP/Grooters, as taught above in claim 20, substantially teaches of the limitations of 
claim 23. TCP, however, does not teach of transmitting the signal as a diffuse infi-ared signal. 
Nonetheless, TCP/Grooters does teach of establishing communication connections. 

Specs, in an analogous art, teaches of diffiise optical communication as a common optical 
communication protocol, see line see hues 3-6 of paragraph 88 on page 28. 
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It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to transmit the frames/packets/broadcast signal of TCP/Grooters using the optical 
communication protocol. This modification would have been obvious because one of ordinary 
skill in the art would have been motivated by the suggestion provided by Specs that diffuse 
optical communication protocol is a commonly used protocol and hence communication method. 

As per claim 24, 

TCP/Grooters, as taught above in claim 20, substantially teaches of the limitations of 
claim 24. TCP/Grooters does not teach of data signal being created by modulating an electric 
light. 

Specs, in an analogous art, teaches of modulating an electric Ught to generate optical 
signals as being known in the art, see line see lines 1-5 of paragraph 161 of page 55. 

It would have been obvious to one of ordinary skill in the art at the time the invention 
was made to create fi-ames/packets/broadcast signal of TCP/Grooters by modulating an electric 
light. This modification would have been obvious to one of ordinary skill in the art would 
because one skilled in the art would have known of the techniques as mentioned by Specs. 
Further, since Specs discloses that the techniques are known in the art, one skilled in the art 
would readily be able to modulate light so as to generate the optical signals with which the data 
signals are transferred over. 

4.9 Claimfs) 25-27 is/are rejected under 35 U.S.C. 103(a) as being unpatentable over RFC 
793 - Transmission Control Protocol Specification (hereinafter TCP) and Grooters (US Patent 
No. 6,684,399) and Krishnakumar. 

As per claim 25, 

TCP substantially teaches of exchanging (and hence transmitting and receiving) 
segments/packets/data signals having a plurality of bytes in paragraph 1 of page 4 and paragraph 
6 of page 40. TCP further teaches of creating frames/packets and headers (integrity elements) to 
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transmit data, see paragraph 1 on page 4 and pages 15-17 and of using the checksum to ensure 
reliability, see paragraph 3, page 4. By teaching of creating the data and 
communicating/transferring it in a specific manner, the Examiner is interpreting that TCP is 
teaching of both how to send and receive the data. When read in this light, it is clear that if TCP 
teaches of how to create frames (packets) and associated integrity elements (headers) and how to 
combine the frames and integrity elements (i.e. append the header to the packet), then TCP 
teaches how to detect and separate packets as well. Further, with TCP teaching of headers and 
what they are corrprised of on pages 15-17, it is clear that TCP teaches of determining the 
contents of the integrity element (header). Further, TCP exphcitly teaches of using the checksum 
(which is one of the contents of the header/integrity element) to disregard damaged 
segments/packets, see paragraph 3 on page 4. 

While TCP does explicitly teach packeting or packaging bytes into frames (or packets) 
containing a subset of the bytes, see paragraph 1 of page 4 and means to reverse such frame 
packeting or packaging, TCP fails to particularly mention that such frame reversal is for 
reverting a "parsing" routine. 

However Grooters, in an analogous art, discloses a network communications wherein 
such techniques are described. {See Grooters, Id, Fig. 3 at step 326 wherein parsing 
routine/reversal-thereof is executed for broadcasting data/HTML/markup-language/XML 
documents.} 

While TCP/Grooters substantially the claimed data signal generation, TCP/Grooters 
fails to disclose in detail that data signal comprises context-relevant information. 

However Krishnakumar et aL, in an analogous art, discloses, in "'Programmable 
protocol engine having context free and context dependent processes'' a network 
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communications wherein such techniques are described. {See Krishnakumar, Id., Fig. 5:Block 
142. 

Therefore, it would have been obvious to a person having ordinary skill in the art at the 
time the invention was made to modify the procedure in TCP/Grooters by including therein a 
context dependent techniques as taught by Krishnakumar, because such modification would 
provide the procedure disclosed in TCP/Grooters with a technique whereby ''Connection context 
data base process 14 also receives information from the parser and it comprises a sequence 
number and state variable generator process 141 which supplies information to a receiver link 
context database 142. Database 142 also receives information from the parser, and it delivers 
information to acknowledge generator process 143. Process 143 supplies information to 
transmitter link context database 144.. " {See Krishnakumar, Fig. 3 at Block 142.} 

As per claims 26 and 27, 

TCP substantially teaches, as noted above in claim 25, the limitations of claims 26 and 
27. With respect to the limitations of claims 26 and 27, TCP further teaches of checking a 
checksum at the receiver to ensure that the segment is not damaged, see paragraph 3 of page 4. 
Clearly, if the checksum is calculated upon receipt and matches the transmitted checksum, then 
the segment/frame/packet will be validated, otherwise, when the two checksums don't match, the 
"damaged" one will be discarded or invalidated. 

Conclusion 

5. Applicant's amendment necessitated the new ground(s) of rejection presented in this 
Office action. Accordingly, THIS ACTION IS MADE FINAL. See MPEP § 609(B)(2)(i). 
Applicant is reminded of the extension of time pohcy as set forth in 37 CFR 1 .136(a). 

A shortened statutory period for reply to this final action is set to expire THREE MONTHS from 

the mailing date of this action. In the event a first reply is filed within TWO MONTHS of the maihng 

date of this final action and the advisory action is not mailed until after the end of the THREE-MONTH 
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shortened statutory period, then the shortened statutory period will expire on the date the advisory action 
is mailed, and any extension fee pxirsuant to 37 CFR 1.136(a) will be calculated from the mailing date of 
the advisory action. In no event, however, will the statutory period for reply expire later than SIX 
MONTHS from the mailing date of this final action. 
5.1 Any response to this action should be mailed to: 

Commissioner of Patents and Trademarks, Washington, D.C. 20231 
or faxed to: (703) 872-9306 for all formal communications. 

Hand-delivered responses should be brought to Customer Services, 220 20^ Street S., Crystal 
Plaza II, Lobby, Room 1B03, Arlington, VA 22202. 

Any inquiry conceming this communication or earlier communications from the examiner should 
be directed to Guy J. Lamarre, P.E., whose telephone number is (571) 272-3826. The examiner can 
normally be reached on Monday to Friday from 9:30 AM to 6:00 PM. 

If attenpts to reach the examiner by telephone are unsuccessfiil, the examiner's supervisor, Albert 
De Cady, can be reached at (571) 272-3819. 

Any inquiry of a general nature or relating to the status of this application or proceeding should 
be directed to the Group receptionist whose telephone number is (571) 272-3609. 

Information regarding the status of an application may also be obtained from the Patent 
Apphcation Information Retrieval (PAIR) system Status information for published applications may be 
obtained from either Private PAIR or Public PAIR. Status information for unpublished applications is 
available through Private PAIR only. For more information about the PAIR system, see 
http://pair-direct.uspto.gov. Should you have questions on access to the Private PAIR system, contact the 
Electronic Business Center (EBC) at 866-217-9197 (toll-free). 
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